1. Field
Example aspects described herein relate generally to mobile wallets in mobile communication devices for use in mobile commerce, and more particularly to systems, methods, and computer program products for managing access control for mobile communication devices that utilize secure elements.
2. Related Art
Mobile communication devices (also referred to herein as mobile devices) are becoming more and more versatile, and are being used in an increasing number of ways to make various everyday tasks simpler and/or more efficient. One area in which mobile devices are being used is mobile commerce. For example, mobile devices are being made to include mobile wallets, which may be used to conduct financial transactions (e.g., payments) and/or non-financial transactions (e.g., venue admissions), without the need for physical cash, checks, credit cards, tickets, and/or the like. In order to safeguard sensitive information (e.g., payment account information) that mobile wallets utilize in conducting such transactions, some mobile devices are made to include, and/or are communicatively coupled to, a secure element that stores such sensitive information.
Controlling access to the secure element is necessary for both security and business reasons. To this end, conventional access control specifications (e.g., Global Platform Access Control (GPAC), for example as described in Global Platform Device Technology—Secure Element Access Control, Version 1.0, Document Reference GPE_SPE_013, May 2012, 86 pages); Gemalto Access Control (GAC); and Public-Key Cryptography Standard No. 15 (PKCS15), each of which is hereby incorporated by reference herein in its entirety, typically require access control rules (also referred to herein as simply “access rules”) to be stored on the secure element.
In general, each access rule in a set of access rules stored on the secure element indicates whether a particular application stored on the mobile device is permitted to access a particular applet stored on the secure element. Any given one of the access rules may correspond to one or more of the applications stored on the mobile device and one or more of the applets stored on the secure element.
Some access control specifications permit the access rules stored in the secure element to be updated (e.g., added, modified, or deleted), for example, by way of a wireless communication protocol, such as an over-the-air (OTA) communication protocol. The secure element also stores a refresh tag (e.g., a flag, a date, a time, and/or another type of temporal indicator) that includes a value that indicates when any of the access rules stored on the secure element was most recently updated. Each time any of the access rules stored on the secure element is updated in the secure element, the value of the refresh tag in the secure element is updated as well.
In some cases, an enforcer module (also referred to herein as “enforcer”) residing on the mobile device retrieves from the secure element, and stores, the set of access rules. According to some access control specifications, the enforcer is required to periodically poll the refresh tag to determine whether any of the access rules stored in the secure element has been updated since the last time the enforcer retrieved the access rules from the secure element. In addition to periodic polling, the enforcer polls the refresh tag of the secure element each time access control is to be enforced (e.g., upon receiving a request for access to information and/or performance of an action that is protected by the rules, such as a request to open a secure communication channel using an application or applet stored on the secure element). If, upon polling the refresh tag, the enforcer determines that one or more pertinent access control rules has been updated since the most recent polling, then the enforcer retrieves from the secure element an updated set of access rules (or a subset of the updated set of access rules), and updates a local set of rules stored on the mobile communication device so as to be consistent with the rules stored in the secure element. One example of such a polling scheme may be found in GlobalPlatform Device Technology—Secure Element Access Control, Version 1.0, Document Reference GPE_SPE_013, Section 5—Remote Interface Based on RAM, May 2012, 86 pages), the entire contents of which are hereby incorporated by reference herein.
In one example, in order to enable the enforcer to determine whether any of the access rules stored in the secure element has been updated since the last time the enforcer retrieved the access rules from the secure element, each time the enforcer retrieves from the secure element, and stores, the access rules, the enforcer also retrieves from the secure element, and stores, the refresh tag that includes a value that indicates when the set of access rules stored on the secure element was most recently updated. In this way, the enforcer may determine whether any of the access rules stored in the secure element has been updated since the last time the enforcer retrieved the access rules from the secure element, by comparing the value of the refresh tag stored in the secure element to the value of the refresh tag stored by the enforcer.
If the value of the refresh tag stored in the secure element matches the value of the refresh tag stored by the enforcer, then that would indicate that the access rules stored by the enforcer are up-to-date; that is, that none of the access rules stored in the secure element has been updated since the last time the enforcer retrieved the access rules from the secure element. If, on the other hand, the value of the refresh tag stored in the secure element does not match the value of the refresh tag stored by the enforcer, then that would indicate that the access rules stored by the enforcer are not up-to-date; that is, that one or more of the access rules stored in the secure element has been updated since the last time the enforcer retrieved the access rules from the secure element. In this case, the enforcer would retrieve from the secure element, and store, the updated set of access rules and the updated value of the refresh tag.
One drawback, however, to polling schemes such as the scheme described above, is that they can result in an inefficient utilization of computing resources, such as the utilization of processor power, processor time, memory, communication channels, and the like. For instance, when no updates have been made to the access rules, polling the refresh tag periodically would needlessly render a processor of the mobile communication device busy.
Likewise, when no updates have been made to the access rules, polling the refresh tag upon receiving a request for information and/or an action protected by the rules would needlessly render the processor busy, and would also negatively impact the user's experience by delaying the granting of the request until after the polling has been completed.
Moreover, even when an update has been made to the access rules, polling the refresh tag upon receiving a request for information and/or an action protected by the rules would negatively impact the user's experience by delaying the granting of the request until after both the polling of the refresh tag and the updating of the local access rules have been completed.
Given the foregoing, it would be beneficial to enable access rules to be updated and enforced in an efficient manner that improves both the user's experience and the utilization of computing resources.